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’Abstract 

The  design  of  a  dynamic  linker  for  use  with  modem  microcomputers  is  intro¬ 
duced.  The  hasic  concents  for  resolving  symbolic  interprocedure  references  at 
execution  time  are  reviewed,  and  the  means  to  support  shared  data  and  (pure) 
procedures  are  explained.  The  mechanism  (modules  and  data  bases)  suitable  for 
microcomputers  without  the  hardware  features  previously  considered  necessary 
for  dynamic  linking  are  described.  The  major  implications  for  the  associated 
operating  system  and  language  translators  are  identified. 
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i .  ivnmj'TrtON 


Oynanic  linking  Provides  a  flexible  and  convenient  way  tor  resolving  a 
procedure's  symbolic  references  to  external  Drocedares  and  data.  It  is  dis¬ 
tinguished  by  when  a  symbolic  reference  is  bound  to  the  (virtual)  address  of 
the  external  object,  viz.,  binding  is  deferred  until  the  first  actual  refer¬ 
ence  during  execution.  Yet  in  soite  of  the  significant  benefits  and  more  than 
a  decade  to  assimilate  the  technology,  the  Multics  system  remains  as  essen- 
tiallv  the  singular  working  example.  Several  authors  of  articles  (n  and 
operating  systems  texts  (2,31  imply  that  a  major  reason  for  this  limited  use 
is  the  special  hardware  required.  We  have  addressed  this  limitation  and  have 
developed  a  dynamic  linker  design  that  requires  no  more  hardware  support  that 
is  Provided  by  modem  microcomputers. 

background 

we  have  used  Multics  [41  as  the  standard  for  the  dynamic  linking  capa¬ 
bilities  we  would  like  to  provide.  Multics  has  an  integrated  hardware  and 
software  design  with  the  hardware  features  that  strongly  support  dynamic  link¬ 
ing  being  (l)  indirect  addressing  through  memory,  (2)  a  linkage  fault  during 
indirection,  (3)  segmentation,  and  (4)  demand  paging. 

Mthough  commercial  microcomputers  do  not  have  the  range  of  hardware 
support  found  in  "dultics ,  they  are  increasingly  capable.  This  has  naturally 
led  to  increased  expectations  for  services,  and  extensive  capabilities  such  as 
full-functioned  languages  (e.g. ,  PL/I)  and  multiorogrammed,  multiprocessor 
operating  systems  (51  are  emerging.  We  believe  that  dynamic  linking  is  an 
attractive  addition  to  this  growing  set  of  system  capabilities. 


q.  Objectives 


We  want  oar  design  to  provide  the  usual  benefits  of  dynamic  linking.  k 
process  should  include  only  those  Procedures  and  data  actually  referenced  dur¬ 
ing  execution,  vice  those  included  in  the  program.  Similarly,  during  software 
develonment  oroqrams  may  be  run  with  references  to  orocedures  (e.q. ,  error 
routines)  not  yet  coded.  Sven  when  all  the  referenced  objects  are  available, 
they  should  be  allocated  (memory)  resources  only  if  the  object  is  actually 
used,  without  the  user  predicting  the  actual  usage  before  program  execution. 

The  dynamic  linker  must  not  seriously  deqrade  other  capabilities  of  the 
system.  have  taken  care  to  accommodate  (but  not  require)  in-core  sharing 
of  (mure)  orocedures  and  data,  mixed  languages  in  a  process,  a  flexible  tile 
system,  and  a  security  kernel  structure  f5)  for  the  ooerating  system.  Pro¬ 
gramming  generality  is  Dreserved  in  that  a  (dynamically  linked)  external 
reference  can  be  used  whenever  an  internal  reference  can  be  used. 

finally,  we  note  that  oerformance  has  been  a  dominant  consideration.  If 
all  programs  'were  interoreted  rath*  :  than  translated  we  clearly  could  simulate 
the  Multics  hardware  supoort  for  dynamic  linking;  however,  for  reasons  of  oer¬ 
formance  we  have  not  chosen  the  interpreter  aooroach.  Our  major  performance 
objective  has  been  to  reduce  to  an  absolute  minimum  the  processing  overhead 
required  for  the  second  and  subsequent  references  to  an  external  object.  Much 
more  processing  is  required  for  the  first  reference  that  must,  of  course, 
create  and  save  (for  subsequent  references)  the  information  on  the  binding 
from  symbolic  reference  to  virtual  address.  The  completion  of  this  first 
reference  is  at  the  heart  of  dynamic  linking. 
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II.  HAHIC  CCMCHPTS  FOP  TWAMIC  LWIT, 


Oynanic  linking  always  occurs  during  the  execution  of  a  procedure  in  the 
address  snace  ot'  a  process.  It  results  from  the  symbolic  reference  to  an 
(explicitly  declared)  external  orocedure  or  data  object.  Oynamic  linking 
implicitly  requires  the  notion  of  a  segment,  i.e. ,  a  logical  groun  of  informa- 
tion  (external  object)  that  retains  distinct  attributes  (e.g. ,  symbolic  name) 
for  the  life  of  the  process.  Mthough  hardware  segmentation  is  not  mandated, 
each  segment  has  an  identifier  (unique  in  each  process)  that  we  will  call  the 
segment  number.  A  segment  number  and  an  offset  within  the  segment  constitute 
a  virtual  address  that  can  be  used  to  reference  a  specific  location. 

On  a  procedure's  first  reference  (in  a  process)  to  an  external  object 
the  dynamic  linker,  with  support  from  the  operating  system,  computes  the  vir¬ 
tual  address  corresponding  to  the  symbolic  reference.  The  linker  stores  this 
binding  in  what  we  call  a  link.  We  then  say  the  link  is  "snapped” ,  and  subse¬ 
quent  references  are  made  through  this  snapped  link  without  use  of  the  linker. 
We  will  next  examine  conceptually  the  functions  and  data  bases  that  make  uo 
the  linker,  and  the  rationale  for  them. 

A.  External  Procedures 

Consider  what  happens  when  a  procedure  segment  <Caller>  executes  the 
first  reference  in  a  process  corresponding  to  the  source  statement: 

CALL  Target 

<Caller>'s  object  code  is  typically  envisioned  as  containing: 

CALL  (virtual  address  of  the  entry  into  <Target»  (l) 

at  the  time  of  execution.  However,  until  <Target>  is  linked  this  is  not 


feasible,  since  its  virtual  address  is  not  known,  we  might  alternatively  con¬ 
sider  translatinq  the  source  into 


m  <Linker>  ("Targef)  (2) 

where  <Linker>  is  a  procedure  serpent  that  calls  on  the  underlying  operating 
system  to  find  the  virtual  address  of  the  entry  tor  the  segment  named  "Tar¬ 
get". 

^ter  determining  the  virtual  address  of  <Tarqet>,  the  liaker  oould 
"snap  the  link”  by  overwritinq  statement  (2)  in  <Caller>’s  object  code  with 
statement  (l) ,  a  call  to  the  <Target>.  This  is  essentially  what  is  done  in 
the  traditional  (static)  linkinq  loader  [11.  However,  to  do  this  dynamically 
tor  a  runninq  proqram  makes  <Caller>  impure,  in  violation  of  our  desiqn  cri¬ 
teria.  To  address  this  we  follow  the  Multics  [41  example,  introducinq  the 
concept  of  a  linkaqe  segment  and  a  linkage  pointer  that  ooints  to  the  section 
(linkage  table)  in  it  for  <Caller>. 

Hvery  process  has  a  distinct  (never  shared)  linkaqe  table  which  contains 
an  outgoing  link  tor  each  external  reference  bv  <Caller>.  The  outgoing  link 
tor  the  reference  to  <Target>  can  be  at  a  fixed  offset  (at  translation)  from 
the  linkage  Pointer.  Thus  the  object  code  of  the  pure  procedure  <Taller>  can 
be  of  the  tom: 

CV.L  (Linkaqe_Po inter  +  <Tarqet>  link  offset)  (3) 

The  outgoing  link  is  designed  to  invoke  <C.inker>  on  the  first  reference  with 
something  similar  to  statement  (l)  above.  The  linker  then  modifies  (i.e. , 
snaps)  the  outgoing  link  to  invoke  <Target>  on  subsequent  references. 

It  miqht  seem  that  the  snaooed  link  should  merely  be  of  the  form  of 
statement  (2)  above.  However,  a  significant  problem  arises,  \fter  the 
transfer  of  control  to  <Target>  we,  of  course,  exoect  the  linkage  Pointer  to 
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point  to  the  linkage  table  for  <Target>,  noe  <Caller>.  Unfortunately,  the 
(our el  code  of  <Target>  cannot  orooerly  load  the  linkage  oointer,  because  the 
appropriate  virtual  address  is  unknown  at  translation  time.  Therefore,  the 
linker  includes  in  the  linkage  table  of  <Target>  an  incoming  link  for  the 
entry  to  <Target>.  Thus  the  proper  form  Cor  the  outgoing  link  from  <Caller> 
is: 

CALL  (<Target>  incoming  link)  (4) 

This  snapoed  incoming  link  contains  a  statement  to  load  the  linkage  pointer, 
followed  by  the  form  of  statement  (l)  to  invoke  <Target>.  This  comoletes  the 
invocation  and  dynamic  linking  of  the  external  procedure  <Target>. 

g.  External  Oata 

An  external  data  reference  has  many  similarities  to  the  above.  Consider 
the  reference  in  <Caller>  corresponding  to  the  source  statement: 
pointer  :=>  AOOP'TSS (Oata) 

The  pure  code  in  <Caller>  will  be  very  similar  to  statement  (3)  for  the  same 
reasons;  in  particular  we  expect  the  form: 

CALL  (Linkage_oo inter  +  Oata>  link  offset)  (5) 

The  unsnaoned  link  in  <Caller>'s  linkage  table  will  be  similar  to  state¬ 
ment  (2)  tor  procedures.  In  particular  the  form 

CALL  <Linker>  ("Data")  («?) 

will  invoke  the  linker  to  obtain  the  virtual  address  of  <Oata>  and  snap  the 
link.  The  snapped  link  is  much  simpler  than  for  procedures,  ’te  need  some¬ 
thing  of  the  form: 

R7TFM  (virtual  address  of  <Oata»  (7) 


This  completes  the  reference  to  and  dynamic  linking  of  the  external  data  seg¬ 
ment. 

III.  TIP  VTOPOOT'P'n'Eh  OYNkHIC  LKW  OEHIOM 

<i.  The  Hteos  in  Establishing  a  Link 

Having  examined  the  basic  concents  of  a  dynamic  linker,  we  will  now 
investigate  the  features  of  a  design  tor  its  realization.  Once  again  the 
steos  (figure  l)  necessary  to  dynamically  link  some  external  orocedure  <Tar- 
getl  entry_name>  (11  to  orocedure  Waller*  will  be  followed,  but  emohasis  will 
be  placed  on  design  details  vice  linking  concents. 

1.  Invoking  the  Linker 

when  <Caller> ’s  source  code  is  translated,  any  external  reference  to 
<Target>  will  be  translated  into  code  which  transfers  the  execution  ooint  to 
an  outgoing  link  in  <Caller>’s  linkage  table  (Caller. link) .  Translated  code 
will  vary  from  system  to  system;  however,  conceotually  we  desire  to  have  a 
oure  orocedure  (<Caller>'s  object  code)  call  some  imoure  orocedure 
(Caller. link) .  This  will  allow  us  at  some  later  ooint  in  the  linking  orocess 
to  convert  the  initialized  outgoing  link  in  Caller. link  from  code  which 
invokes  the  linker  to  code  which  will  result  in  the  invocation  of  CTargetl 
entry_name> . 

we  have  mentioned  that  the  outgoing  link  is  initialized  to  invoke  the 
linker.  One  method  to  do  this  would  be  for  the  outgoing  link  to  oroduce  a 

(l)  5ntry_name  reoresents  a  label  within  <Target>  which  can  be  referenced  by 
an  external  orocedure.  *n  entry  ooint  is  an  offset  within  <Target>  associated 
with  some  entry  name. 


events  for  snapping  the  link  to  the  procedure  TargetlEntry  Name. 


hardware  fault  which  will  invoke  the  linker  as  a  fault  handler.  (This 
represents  the  most  qeneral  of  the  methods  available  and  is  the  method  used  in 
Hultics.)  However,  barring  this  capability,  the  linker  mav  be  invoked  via  a 
direct  jump  in  the  outqoinq  link.  In  both  these  methods  the  linker  would  be 
passed  the  offset  of  the  symbolic  name  <Tarqet!  entrvjiame^  in  <Caller>'s  sym¬ 
bolic  name  table  (Caller. sym) .  (hn  object's  symbolic  name  table  stores  the 
symbolic  names  of  all  external  references  in  a  procedure.  ’Viditionally  it 
will  be  used  to  retain  entry  names  and  their  associated  entry  Doints  utilized 
within  the  Procedure.)  \  third  mechanism  to  invoke  the  linker  is  via  an 
explicit  call  in  <Caller>'s  source  code  passing  to  the  linker  the  symbolic 
name  of  the  object  to  be  linked  as  a  actual  parameter.  (This  represents  a 
soecial  case  which  will  be  discussed  later.) 

C.  Snapping  the  Link 

The  question  naturally  arises  of  how  the  linker  knows  where  Caller. svm 
is  located.  We  have  Provided  a  mechanism  to  resolve  this  problem  by  placing 
the  virtual  address  of  an  object’s  symbolic  name  table  in  a  header  in  the 
object's  linkage  table.  (We  can  always  find  an  object's  linkage  table  since 
we  propose  to  store  a  pointer  to  it  in  a  linkage  address  table.)  Thus  the 
linker  can  access  the  <Tarqetl  entry_name>  by  utilizing  the  virtual  address  of 
the  symbolic  name  table  (from  the  linkage  table  header)  and  the  offset  it  was 
passed  as  a  formal  parameter. 

The  linker  will  then  pass  the  symbolic  name  <Target>  to  a  module  in  the 
supervisor  called  the  address  space  manager  (which  will  be  discussed  in  more 
detail  later) .  ht  this  point  we  will  consider  the  address  space  manager  a 
routine  'which,  when  passed  a  symbolic  name,  enters  the  object  associated  with 
that  symbolic  name  in  the. address  space  of  the  executing  process  and  returns 


to  the  linker  the  segment  number  assigned  to  that  object. 


Now  that  we  know  the  segment  number  ot  <Target> ,  we  can  generate  a  com- 
olete  virtual  address  tor  <Tarqetl  entry_name>  by  accessing  the  entry  point 
into  <Tarqet>  associated  with  'entry__name' .  hecall  that  the  symbolic  name 
table  ot  an  object  contains  not  only  the  symbolic  names  of  external  refer¬ 
ences,  but  also  entry  names  (and  their  associated  entry  points)  into  the 
object.  Thus  if  we  can  access  Target. sym  we  can  find  the  entry  point  associ¬ 
ated  with  '  entry jiame'.  When  the  segment  number  of  <Target>  is  returned  to 
the  linker,  the  linker  will  construct  a  linkage  table  for  CTarget^  (if  one 
does  not  already  exist)  to  allow  <Target>  to  engage  in  dynamic  linking.  Since 
the  header  of  Target. link  contains  the  virtual  address  of  Target. sym,  we  can 
find  the  entry  noint  corresponding  to  'entryjiame'. 

We  now  have  a  virtual  address  (of  the  form  <segment  number! 
entry_point»  and  could  invoke  <Targetl  entry_name>  at  this  Point.  However, 
we  would  like  to  retain  this  virtual  address  to  simplify  subsequent  invoca¬ 
tions  of  <Tarqet!  entry_name>.  We  can  accomplish  this  goal  bv  storing  the 
virtual  address  of  <Tarqetl  entrvjnane>  in  Target. link.  \n  incoming  link  has 
been  set  aside  for  this  purpose  and  we  can  transfer  control  to  this  incoming 
link  on  subsequent  calls  by  replacing  the  jump  to  the  linker  found  in  the  out¬ 
going  link  (in  Caller. link)  with  a  jump  to  the  incoming  link  (tor  <Targetl 
entry_name» .  Thus  subsequent  calls  will  follow  the  sequence  shown  in  figure 
2. 

hecall  that  the  linkage  Pointer  is  used  to  indicate  the  start  of  the 
currently  executing  procedure's  linkage  table.  Thus  when  we  start  executing 
in  <Target>,  we  want  the  linkage  pointer  to  point  to  Target. link.  The  incom¬ 
ing  link  for  <Tarqet!  entry_name>  will  be  used  to  set  the  linkage  Pointer 
(prior  to  transferring  control  to  CTargetl  entry_nane» .  This  implies  that 
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when  <Caller>  calls  an  outgoing  lin’<  the  linkage  no  inter  (which  Points  to 
Waller. lin'<)  must  be  saved  and  furthermore  must  be  restored  when  the  orocess 
execution  ooint  returns  from  <Target>  to  <baller>.  This  may  be  done  automati¬ 
cally  by  the  hardware  OhLL/hCT'IRM  sequence  or  explicitly  by  the  object  code  in 
<Caller>. 

3.  Linking  bata 

The  stens  to  link  data  differ  slightly  from  those  for  linking  pro¬ 
cedures.  fundamentally,  data  is  not  executed  and  does  not,  therefore,  have 
the  caoability  to  initiate  dynamic  linking.  Thus  if  <Caller>  were  to  refer¬ 
ence  some  data  object,  <batal  entry_nane>,  instead  of  invoking  <Oata|  entry- 
nan^  all  we  really  want  to  know  is  its  virtual  address,  Me  therefore  orooose 
that  when  snapoed,  the  outgoing  link  for  <Data|  entry_name>  will  load  some 
pointer  register  with  the  virtual  address  of  <bata|  entry_name>  and  then 
return  to  <baller>.  The  sequence  for  subsequent  references  to  <Oatal  entry 
name>  is  shown  in  '’inure  3. 

'•fe  note  that  the  use  of  entry  names  within  data  implies  that  the  data 
must  undergo  a  translation  and  have  a  symbolic  name  table  and  linkage  table. 
These  two  items  nay  be  merged  into  one  structure  since  the  data  linkage  table 
consist  of  a  header  which  (at  this  ooint)  only  contains  a  Pointer  to  the  data 
symbolic  name  table. 


A.  'Jnlmking 


In  a  microcomputer  environment,  there  may  exist  a  limited  number  ot  seg¬ 
ments  available  tor  use  by  a  process  (2) .  To  nrohibit  this  from  limiting  the 
size  ot  programs,  we  may  choose  to  unlink  objects  from  an  address  soace  in 
order  to  allow  the  dynamic  linking  ot  new  objects  to  the  process. 

1.  fundamentals  of  'Inlinking 

Conceptually  unlinking  is  a  trivial  Process  but  may  include  Pitfalls 
which  must  be  taken  into  account.  To  unlink,  an  object  is  selected  for  remo¬ 
val,  the  object's  entry  in  the  linkage  address  table  is  erased,  and  all  outgo¬ 
ing  links  to  the  object  are  reset  to  their  presnapoed  format.  This  implies 
two  major  points.  First,  any  data  required  to  reset  an  outgoing  link  must 
either  be  accessible  by  some  means  or  stored  in  the  outgoing  link  itself. 
Secondly,  we  must  be  able  to  find  each  snapped,  outgoing  link.  It  is  proposed 
that  a  linked  list  of  outgoing  links  referring  to  an  object  be  formed  with  a 
pointer  to  the  start  ot  this  linked  list  stored  in  the  object's  linkage  table 
header.  Thus,  in  the  trivial  case,  unlinking  an  object  consist  of  erasing  the 
object's  entry  in  the  linkage  address  table,  resetting  each  outgoing  link  in 
the  object's  linked  list,  and  finally  deleting  the  object  and  its  linkage 
table  from  the  process  address  space. 

2.  Resolving  Addressing  in  the  Combined  Linkage  Table 

Recall  that  we  said  there  were  pitfalls  involved  in  unlinking.  These 
arise  from  how  an  object's  linkaqe  table  is  entered  in  a  process  address 

(2)  As  an  example,  the  29000  microprocessor  [7]  with  one  Memory  Management 
'Init  allows  a  maximum  of  54  segments,  some  of  which  must  be  assigned  to  the 
operating  system. 


space.  Observe  that  it  we  are  concerned  with  unlinking,  there  are  not  ade¬ 
quate  serpents  available  to  assign  each  linkage  table  a  unique  sequent  number. 
It  is  proposed  that  in  such  an  environment,  individual  linkage  tables  be  com¬ 
bined  into  a  single  segment  which  we  will  call  the  combined  linkage  table. 

'Sven  though  the  combined  linkage  table  conserves  segments,  it  creates 
addressing  Problems  which  must  be  taken  into  account.  It,  when  removing  a 
deleted  object's  linkage  table  from  the  combined  linkage  table,  a  compaction 
ot  the  combined  linkage  table  is  performed,  some  remaining  linkage  tables  may 
be  relocated. 

This  relocation  requires  the  following  three  addressing  oroblems  be 
resolved:  (l)  a  relocated  linkage  table  must  have  its  entry  in  the  linkage 
address  table  updated,  (7)  outgoing  links  which  transfer  control  to  an  incom¬ 
ing  link  in  a  relocated  linkage  table  must  be  undated,  (3)  nodes  of  an 
(unlinker)  linked  list  ooincing  to  outgoing  links  in  a  relocated  linkage  table 
must  be  undated. 

\  fourth  addressing  nroblem  which  must  be  resolved  involves  the  removed 
object's  linkage  table.  Sach  outgoing  link  in  this  linkage  table  is  a  node  in 
a  linked  list  and  must  be  deleted  from  that  linked  list  nrior  to  removing  the 
linkage  table  from  the  process  address  soace.  (We  note  that  a  doubly  linked 
or  circular  linked  list  ot  outgoing  links  is  helpful  in  resolving  these  last 
two  addressing  problems.) 

3.  Selecting  an  Object  for  Removal 

\  brief  comment  is  in  order  concerning  the  selection  ot  an  object  tor 
removal.  \  procedure  cannot  be  unlinked  and  removed  from  the  address  soace  it 
it  has  a  current  activation  record  since  this  would  break  the  integrity  ot  the 
return  sequence  from  a  series  ot  one  or  more  procedure  calls.  Therefore  a 
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mechanism  nusc  he  developed  to  test  tor  this  condition  orior  to  selecting  an 
object  for  removal.  This  implies,  tor  example,  that  the  initial  orogram  can¬ 
not  be  unlinked  since  it  is  always  either  executing  or  in  the  return  sequence. 

tv.  g'poohr 

should  now  like  to  briefly  discuss  operating  system  support  for 
dynamic  linking.  It  is  felt  that  the  capabilities  discussed  either  already 
exist  or  are  imolementable  in  most  microcomputers. 

’V.  The  Uddress  Hoace  Manager 

The  address  space  manager  serves  as  an  interface  between  the  dynamic 
linker  and  the  ooerating  system.  It  will  call  on  ^ile  System  Management  and 
(in  some  cases)  Memory  Management  to  obtain  data  which  allows  it  to  convert 
the  symbolic  name  of  an  object  into  an  addressable  entity.  Having  done  this, 
the  address  space  manager  will  save  this  data  in  a  table  (which  we  will  call 
the  process  reference  table)  to  prevent  unnecessary  invocations  of  operating 
system  routines  for  subsequent  request  to  make  an  object  addressable  bv  a  Pro¬ 
cess.  we  note  that  the  process  reference  table  is  a  ’per  process’  data  struc¬ 
ture  and  each  object  entered  in  it  has  a  unique  set  of  attributes  (such  as 
segment  number,  access  rights,  etc.)  with  resoect  to  that  process. 

'"ben  passed  a  symbolic  name,  the  address  space  manager  must  be  able  to 
access  the  object  associated  with  that  symbolic  name  in  order  to  make  the 
object  addressable  by  the  process.  The  address  space  manager  will  return  to 
the  dynamic  linker  a  unique  orocess-identifier  associated  with  that  object. 
This  object  identifier  has  been  assumed  to  be  the  segment  number  assigned  to 
the  object,  however  conceptually  all  an  object  identifier  must  do  is  to  allow 


the  linker  (and  the  user  process)  to  address  the  object  in  sene  fashion. 

Translator  Support 

Pecall  that  the  linker,  using  some  format  or  template,  must  build  a 
linkage  table  tor  each  object  when  that  object  is  entered  in  the  process 
address  soace.  The  existence  of  this  template  and  additionally,  the  existence 
of  the  symbolic  name  table,  imply  that  the  translator  used  must  support 
dynamic  linking  by  not  only  translating  external  references  and  recognizing 
entry  names,  but  also  by  constructing  a  linkage  table  template  and  symbolic 
name  table  tor  the  translated  object.  ’is  will  be  shown,  it  is  reasonable  to 
assume  that  a  translator  can  be  designed  (or  modified)  with  this  capability 
since,  in  general,  all  data  necessary  to  construct  these  two  items  is  either 
easily  computable  or  available  in  the  translator's  symbol  table. 

1.  The  Symbolic  Name  Table 

The  symbolic  name  table  (figure  4)  contains  an  entry  for  each  unique 
external  reference  and  entry  name.  In  addition,  the  linkage  table  offset  of 
the  corresponding  link  (i.e.,  outgoing  and  inooming  links)  for  each  symbolic 
name  table  entry  should  be  stored  with  that  entry,  we  note  that  this  is  man¬ 
datory  for  entry  names;  however,  tor  external  references,  the  addition  of  the 
(outgoing)  link  offset  is  only  convenient  since  it  removes  the  requirement  for 
the  linker  to  store  this  information. 

It  is  reasonable  to  ask  where  the  symbolic  name  table  is  located  in  a 
process  address  space,  hecall  that  for  the  data  object  <Oata>,  we  have  sug¬ 
gested  that  bata.sym  be  appended  to  Oata. link.  (This  implementation  allows 
<Data>  to  be  based  at  offset  zero  and  to  grow  dynamically.)  '^e  could  use  this 
solution  for  a  procedure  also;  however,  since  the  symbolic  name  table  does  not 
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change,  a  separate  cony  tor  each  process  is  not  needed.  \  reasonable  solution 
theretore  would  be  to  append  the  symbolic  nape  table  to  the  end  ot  a  (pure) 
procedure's  object  code. 


t  .  • 

I  , 


2.  The  Linkage  Table  Template 


The  linkage  table  template  (figure  5)  should  reflect  the  exact  format  of 
an  initialized  linkage  table  with  one  exception.  We  have  stated  that  the 
header  of  a  linkage  table  contains  the  virtual  address  of  that  object's  sym¬ 
bolic  name  table  yet  at  translation  time  the  segment  number  of  the  symbolic 
name  table  is  unknown.  Theretore,  we  must  construct  this  virtual  address  when 
the  linkage  table  of  an  object  is  built.  If  the  symbolic  name  table  is  a  part 
of  the  object  code,  its  virtual  address  can  be  computed  (given  we  know  the 
offset  of  the  symbolic  name  table  in  the  object  code)  when  the  object’s  seg¬ 
ment  number  is  obtained  from  the  address  soace  manager.  If  the  symbolic  name 
table  is  a  part  of  the  linkage  table,  we  can  obtain  the  linkage  table  segment 
number  via  the  linkage  address  table. 

wotice  that  the  header  of  figure  5  includes  an  entry  reflecting  the  size 
of  the  linkage  table.  This  represents  useful  information  if  an  unlinker  is 
implemented  (by  providing  the  unlinker  with  the  size  of  a  linkage  table  to  be 
removed)  and  may  Provide  useful  data  when  loading  a  linkage  table  in  a  process 
address  soace. 

9y  building  the  symbolic  name  table  first,  the  construction  of  the  body 
of  a  template  becomes  quite  trivial  for  the  translator,  we  note  that  there  is 
a  one-to-one  mapping  between  entries  in  the  linkage  table  and  the  symbolic 
name  table.  Therefore  the  template  can  be  easily  constructed  by  scanning  the 
symbolic  name  table  and  initializing  a  link  compatible  with  each  particular 
symbolic  name  table  entry.  *s  each  link  is  initialized,  we  can  also  enter  its 
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link  offset  into  its  respective  symbolic  name  table  entry. 

It  is  reasonable  to  ask  where  in  a  svsten  the  linkaqe  table  template 
should  be  located.  It  is  suqgested  that  unless  demand  paqinq  is  available,  a 
separate  tile  tor  the  template  be  created.  This  will  allow  the  construction 
ot  a  linkaqe  table  without  requirinq  that  the  template  be  entered  in  a  Process 
address  space.  In  a  demand  oaqinq  environment,  the  linkage  table  template  can 
be  a  part  ot  the  object  code  and  once  it  has  been  utilized  to  construct  the 
linkaqe  table,  it  will  be  'oaged  out'  of  main  memory  since  it  will  not  be 
further  referenced. 

0.  Process  Initialization 

^uch  work  by  Janson  [9,91  has  been  devoted  to  process  initialization 
including  a  complete  description  ot  how  the  dynamic  linker  and  the  operating 
system  are  linked  in  a  multi-domain  environment.  Our  design  has  been  guided 
by  these  results.  It  should  be  noted  that  Process  initialization  must  include 
the  process  reference  table  and  linkaqe  address  table.  With  resoect  to  a 
user's  oroqram,  process  initialization  in  a  dynamic  linkinq  environment 
differs  only  in  that  the  linkaqe  table  for  the  user  oroqram  must  be  entered  in 
the  process  address  snace  and  the  linkaqe  pointer  initialized  prior  to  com¬ 
mencing  Program  execution. 

V.  LIVkIOO  WITHOUT  T9V4SL\TOq  S'F®OPT 

Having  implied  that  translator  suooort  is  necessary  to  realize  dynamic 
linking,  we  would  like  to  summarize  an  implementation  in  an  environment  where 
this  condition  does  not  hold;  the  implementation  details  have  been  given  else¬ 
where  [101.  It  is  felt  that  a  linker  in  this  environment  should  meet  certain 
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fundamental  requirements,  ’’'irst,  we  would  like  to  use  the  same  dynamic  linker 
to  link  both  (translator)  supported  and  unsupported  objects  thus  requiring 
onlv  one  linker  and  additionally  allowing  a  orocess  to  utilise  both  object 
tyoes.  Mso,  we  do  not  wish  to  have  to  exolicitlv  declare  in  our  source  code 
an  external  object  to  be  suooorted  or  unsuooorted  since,  it'  that  object  is 
retranslated  with  a  type  change  (e.g.,  unsuooorted  to  supported),  all  oro- 
cedures  referring  to  that  object  would  have  to  be  retranslated  also.  (This 
imnlies  that  the  linker  must  be  able  to  differentiate  between  supoorted  and 
unsuooorted  objects.) 

The  Interface  Module 

Oecall  that  we  have  offered  an  exolicit  call  to  the  linker  in  a 
orocedure's  source  code  as  a  mechanism  for  linker  invocation  such  as 
■CV.L  <LIMK>  (Target) 

In  this  examole,  <LtMT<>  is  a  nodule  which  is  statically  linked  to  a  orocess 
and  serves  as  an  interface  between  the  orocess  and  the  dynamic  linker.  Con- 
ceotually,  <LIM’<>  must  carry  out  those  functions  which,  in  a  (translator)  suo¬ 
oorted  system  involve  the  translator. 

h.  Linking  Mnsuooorted  Objects 

We  will  now  investigate  the  steos  necessary  to  link  the  unsuooorted 
object  <Target>  to  the  unsuooorted  orocedure  <Caller>  (figure  . 

When  <LTWK>  is  called  it  will  enter  <Target>  in  the  next  free  location 
in  Caller. sym  and  will  build  an  initialized  outgoing  link  tor  <Target>  in 
Caller. link.  (If  <Target>  already  has  an  entry  in  Caller. sym,  it  also  has  a 
snaoped  link  and  all  that  is  required  is  to  execute  the  snaooed  link.)  <LIMK> 
will  then  load  <Target>'s  parameters  into  the  system  according  to  translator 


conventions  and  execute  the  outgoing  lin'<. 

’'hen  the  linker  identities  <Target>  as  unsupported,  it  will  cause  a 
block  ot  virtual  memory  to  be  allocated  to  serve  as  Tarqet.link  and  Target. syn 
(since  <Tarqet>  has  neither  a  symbolic  name  table  nor  linkage  table  template) . 
Once  Tarqet.link  and  Tarqet.svm  have  been  initialised,  the  linker  will  enter 
<Target>  as  the  only  entry  name  in  Target. sym  and  conolete  the  link  by  snap¬ 
ping  the  incoming  link  in  Tarqet.link  (provided  <Target>  is  a  Procedure). 

d.  The  Interface  Linkage  °o inter 

We  canrwt-  exoect  that  an  unsupported  translator  will  know  that  the  link¬ 
age  pointer  hardware  register  is  not  available  for  general  use  and  therefore 
must  assume  that  it  cannot  be  used  to  Point  to  the  linkage  table  of  an  execut¬ 
ing  unsupported  procedure.  We  therefore  propose  that  an  interface  linkage 
pointer  be  established  (in  software)  by  <LIVK>  to  duplicate  the  functions  of 
the  hardware  linkage  oointer. 

We  should  like  to  observe  two  important  ooints.  S'irst,  the  incoming 
link  to  <Target>  must  set  the  interface  linkage  oointer  to  point  to 
Tarqet.link  vice  the  hardware  linkage  pointer.  Second,  if  a  process  executes 
both  supported  and  unsupported  procedures,  the  first  Procedure  executed  must 
be  supported  since  this  ensures  that  the  hardware  linkage  pointer  is  saved 
before  it  can  be  subject  to  general  use  by  an  unsuDoorted  procedure. 

O.  The  Oisadvantages  of  'Jnsuooorted  dynamic  Linking 

There  are  four  major  disadvantages  when  linking  in  an  unsupported 
environment.  To  begin  with,  subsequent  references  to  a  linked  object  will  be 
executed  much  slower  than  in  a  supported  system  since  housekeeping  functions 
associated  with  linking  are  carried  out  by  software  routines  vice  object 


(machine)  code.  Secondly,  we  have  not  proposed  a  mechanism  to  pass  external 
Procedures  to  subroutines  as  actual  parameters.  \  third  disadvantage  relates 
to  nultinle  entry  noints.  Since  the  identification  ot  entrv  names  and  their 
associated  entry  noints  requires  translator  support,  an  unsuooorted  object  can 
only  be  accessed  at  one  entry  noint  (viz.  ,  its  startinq  location).  \  fourth 
disadvantaqe  is  that  external  data  will  be  limited  to  a  based  variable  similar 
to  those  found  in  °L/T  or  PL/^l  since  <LIMk>  can  only  return  to  the  point  of 
call  a  pointer  to  the  external  data. 

VT .  HVTWTJ  IMPLtCYHOMS 


havinq  discussed  the  desiqn  of  a  dynanic  linker  to  execute  on  currently 
available  microprocessors ,  we  would  like  to  examine  hard-ware  features  -which 
are  advantageous  in  a  dynanic  linkinq  environment.  The  hardware  features  dis¬ 
cussed  can  be  classified  into  two  qeneral  qrouns:  those  -which  influence  the 
desiqn  of  the  dynamic  linker  and  chose  which  affect  the  svsten  performance  by 
imerovinq  execution  sneed. 

hardware  features  htfectinq  r.inkinq  besiqn 

’-re  will  discuss  four  hardware  features  which  affect  the  desiqn  ot  a 
dynamic  linker.  To  beqin  with,  the  abilitv  to  invoke  the  linker  via  a 
hardware  fault  ensures  that  a  completely  qeneral  desiqn  can  be  implemented. 
Without  this  capability,  a  link  must  be  snapped  when  external  data  is  passed 
as  an  actual  parameter  to  a  subroutine  (viz. ,  when  the  call  is  executed) , 
immlvinq  that  a  link  may  be  snaooed  prior  to  first  reference.  The  second 
desirable  hardware  feature  involves  the  capability  to  reference  external 
objects  via  indirect  addressinq.  It  this  feature  exists,  snapped  outqolnq 


links  are  sinoly  virtual  addresses  for  indirect  addressing  instructions. 
(Multics  utilizes  indirect  addressinq  and  a  linkage  fault  on  indirection  in 
the  implementation  of  its  dynamic  linker  C^l.) 

\  third  influencinq  feature  involves  the  size  of  (hardware)  virtual 
memory.  ''’e  note  if  an  adequate  number  of  seqments  exist  (assuminq  each  seq- 
ment  is  of  reasonable  size) ,  it  may  not  be  necessary  to  implement  an  unlinker. 
(We  can  always  conserve  seqment  numbers  by  combininq  smaller  objects  into  one 
seqment  orior  to  execution  and  reterencinq  each  object  via  an  entry  Point.) 
The  final  feature  has  already  been  mentioned  and  is  the  ability  to  save  and 
restore  the  linkaqe  pointer  as  a  part  of  the  microprocessor’s  CV/.  and  h'rr’JhN 
conventions. 

q.  Performance  Considerations 

Mong  the  lines  of  system  performance  we  will  discuss  two  hardware 
features:  the  hardware  relocatability  of  code  and  hardware  segmentation. 
These  are  supported  by  modem  microprocessors  such  as  the  Ziloq  ZhOOO  (7)  and 
the  Intel  successor  (111 . 

with  respect  to  hardware  relocatability,  we  note  that  one  must  have 
relocatable  procedure  seqments  to  implement  a  dynamic  linker  since  at  the 
start  of  Program  execution,  there  exist  no  bindings  between  procedures  and 
process  virtual  addresses.  Therefore,  the  more  efficiently  procedures  can  be 
relocated  (viz.,  hardware  relocation),  the  better  system  performance  will  be. 

We  have  maintained  that  a  dynamic  linker  can  be  implemented  without 
hardware  segmentation  as  long  as  individual  objects  can  be  referenced  as  logi¬ 
cal  entities  (i.e. ,  segments).  This  implies  that  many  functions  intrinsic  to 
a  segmented  system  must  be  available  in  a  dynamic  linking  environment.  It  is 
only  logical,  therefore,  to  oonclude  that  it  is  advantageous  to  have  hardware 


segmentation.  In  particular,  the  in-core  sharing  ot  objects  (e.g.  ,  cure  Pro¬ 
cedures!  in  a  multiprogramming  environment  is  extremely  difficult  to  implement 
without  the  support  of  hardware  segmentation. 

’/It.  OOMCL'JSTONS 

we  have  presented  a  design  that  illustrates  the  feasibility  of  dynamic 
linking  in  a  microcomputer  environment.  ,'te  have  shown  that  there  are  only 
modest  demands  on  the  supporting  language  translators,  operating  system,  and 
hardware.  On  the  other  hand,  the  design  is  not  in  conflict  with  the  more 
sophisticated,  state-of-the-art  capabilities  that  can  be  expected  tor  micro¬ 
computers  ot  the  future,  furthermore,  the  Performance  cost  is  quite  moderate: 
the  operations  tor  the  first  reference  are  essentially  those  ot  the  tradi¬ 
tional  linking  loader.  Subsequently  we  require  about  three  additional 
instructions  per  external  call  and  about  two  net  external  data  reference. 
Thus,  we  conclude  that  it  is  Possible  and  practical  to  include  the  substantial 
benefits  ot  dynamic  linking  in  the  set  of  capabilities  tor  present  and  future 
microcomputers . 
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